Prototyping a process-centered environment

This paper describes an experimental system developed and used as a vehicle for prototyping the Arcadia-1 software development environment. Prototyping is viewed as a knowledge acquisition process and is used to reduce risks in software development by gaining rapid feedback about the suitability of a production system before the system is completed. Prototyping a software development environment is particularly important due to the lack of experience with them. There is an acute need to acquire knowledge about user interaction requirements for software environments. These needs are especially important for the Arcadia project, as it is one of the first attempts to construct a process-centered environment. Our prototyping effort addresses questions about effective interaction with a process-centered environment by simulating how Arcadia-1 would interact with users in a representative range of usage scenarios. We built a prototyping system, called PRODUCER, and used it to generate a variety of prototypes simulating user interactions with Arcadia-1 process programs.Experience with PRODUCER indicates that our approach is effective at risk reduction. The prototypes greatly improved communication with our customer. They confirmed some of our design decisions but also redirected our research efforts as a result of unexpected insight. We also found that prototyping usage scenarios provides conceptual guides and design information for process programmers. Most of the benefits of our prototyping effort derive from developing and interacting with usage scenarios, so our approach is generalizable to other prototyping systems. This paper reports on our prototyping approach and our experience in prototyping a process-centered environment

Prototyping a process-centered environment

This paper describes an experimental system developed and used as a vehicle for prototyping the Arcadia-1 software development environment. Prototyping is viewed as a knowledge acquisition process and is used to reduce risks in software development by gaining rapid feedback about the suitability of a production system before the system is completed. Prototyping a software development environment is particularly important due to the lack of experience with them. There is an acute need to acquire knowledge about user interaction requirements for software environments. These needs are especially important for the Arcadia project, as it is one of the first attempts to construct a process-centered environment. Our prototyping effort addresses questions about effective interaction with a process-centered environment by simulating how Arcadia-1 would interact with users in a representative range of usage scenarios. We built a prototyping system, called PRODUCER, and used it to generate a variety of prototypes simulating user interactions with Arcadia-1 process programs.Experience with PRODUCER indicates that our approach is effective at risk reduction. The prototypes greatly improved communication with our customer. They confirmed some of our design decisions but also redirected our research efforts as a result of unexpected insight. We also found that prototyping usage scenarios provides conceptual guides and design information for process programmers. Most of the benefits of our prototyping effort derive from developing and interacting with usage scenarios, so our approach is generalizable to other prototyping systems. This paper reports on our prototyping approach and our experience in prototyping a process-centered environment

Programming a Software Requirements-Specification Process

this paper, we describe REBUS and aspects of its development and use. Section 2 discusses current approaches to software requirements specification and explains our choice of requirements specification for the prototype process. The next three sections discuss the development of REBUS: Section 3 presents goals for the prototyping experiment and sets out requirements for the process program, Section 4 presents product and process models for REBUS, and Section 5 describes the design and implementation of REBUS in APPL/A. Section 6 then describes our experience in using REBUS. Finally, Section 7 provides a discussion of our experience and the issues raised, and Section 8 summarizes our conclusions and indicates future work